Current mainstream operating systems (OSes), such as Microsoft WINDOWS XP, WINDOWS Vista, and WINDOWS 7, require idle devices to stay in a powered on state (but otherwise in a low-power state) to allow access to the Peripheral Component Interconnect (PCI) configuration space (a memory area that contains configuration information) of a connected device while the OS is running. Due to power leakage and other power impacts, the power draw of an idle device and the bus interface connecting the device to the rest of the system may be hundreds of milliwatts (mW) to several watts (W), depending on the hardware.
The Microsoft OSes do not allow driver-controlled arbitration of these accesses, like other OSes in the market (e.g., Apple's Mac OS or Linux 2.6.xx with appropriate configuration). Therefore, fully powering off the device requires lengthy and complex software mechanisms that take multiple seconds to perform.
While some OSes support a per-device D3cold state (where primary power is fully removed from the device) for PCI devices that are currently not in use, the Microsoft OSes do not. Due to this deficiency, current platform designs that want to realize additional power savings by avoiding bus interface and device power leakage are required to use OS-based plug and play (PnP) mechanisms to remove and attach the device. But those mechanisms introduce a long latency (around 3-7 seconds on WINDOWS Vista) until the device is fully powered on.
For non-PCI configuration space registers, control of the device registers is managed by the independent hardware vendor (IHV) drivers. Access to the PCI configuration space of the device can occur at arbitrary times by both the OS and low-level system software. Serious platform stability issues may occur if the device is powered off during the attempted access. The accesses mostly generate from the Microsoft PCI class driver without an OS-designed mechanism for access control by clients. One possible approach to remedy this involves replacing OS functionality with a filter driver, which has implications for system stability and WINDOWS Hardware Quality Labs (WHQL) device certification in some scenarios. There are some benefits in providing hardware assistance in the platforms' Root Complex for this purpose.
Existing ways of powering off a PCI device include using PnP operation, device voltage islands, and a PCI filter driver.
1. With PnP operation, the software uses OS mechanisms to virtually attach and detach the driver from operation (e.g., PnP Stop/PnP Start). After the device has been removed from OS operation, the device hardware can be powered off. This solution has disadvantages, including being intrusive to software, the OS and running applications may lose the device state and need to reinitialize, and not all applications may survive the device being powered down and may need to be restarted. This solution takes multiple seconds to complete, on average a minimum of 5-10 seconds on current OSes.
2. Device voltage islands involve isolating the device bus interface from the rest of the device to power off these sections independently. Configuration space accesses are still allowed while the rest of the ASIC is powered off. This solution has disadvantages because the bus interface is still powered, causing leakage and other power consumption adding up to an additional power draw of 0.4-3 W, depending on the actual hardware.
3. An OS-based PCI filter driver is a software filter driver that detects and redirects accesses to the configuration space through the PCI filter driver to a system memory location. This solution is fragile, because the filter driver that needs to be installed will not work in some OS operating modes and there are mechanisms (e.g., hardware virtual machine (VM), direct input/output (I/O) to CF8/CFC, and system management mode (SMM)) that are not detectable by this mechanism. Any such access may cause the system to hang.